Après avoir couvert les modules pour les processus principal et de rendu, nous pouvons maintenant jeter un
coup d'œil aux très importants modules de messagerie IPSI utilisés pour communiquer entre ces processus.
IPC signifie Inter Process Communication.
Et si vous vous souvenez de la leçon sur le module distant, c'est ce que le module distant utilise pour communiquer avec
le processus principal depuis le moteur de rendu.
La raison pour laquelle j'ai séparé ce sujet dans sa propre section est qu'ELECTRON nous fournit deux modules pour
la messagerie IPSI, IPC principal pour la gestion de l'époxy sur le processus principal et le moteur de rendu époxy à utiliser dans le processus
de rendu.
Ces deux modules s'appuient l'un sur l'autre pour implémenter IPSI.
Je vais commencer par Mendes où nous utiliserons l'époxy Maine.
Donc, exigez ce module de l'électron époxy principal.
Cela nous permet désormais d'envoyer des messages à un processus de rendu ou à une fenêtre de navigateur et d'écouter les
messages entrants.
Si nous regardons la documentation de ce module, nous voyons que c'est relativement simple.
Cela ressemble beaucoup à un module d'événement standard šemeta.
Nous pouvons commencer par écouter un message du processus de rendu de la fenêtre principale dans
la portée globale, disons IPSI Main sur lequel peut également être une fois.
Si vous souhaitez supprimer l'écouteur après avoir reçu le premier événement de message.
Je m'en tiendrai pour l'instant avec le premier paramètre étant le canal sur lequel écouter les canaux étant
uniques, les identifiants sur lesquels envoyer et écouter les messages.
Nommer à cette chaîne le nom réel de la chaîne n'ayant absolument aucune signification.
Mais écouter sur Channel One de cette manière signifie que seuls les messages envoyés à ce canal à partir du
moteur de rendu seront reçus, ce qui permet essentiellement d'identifier et d'organiser le trafic ABC.
Cela prend un rappel à exécuter lors de la réception d'un message, le premier paramètre étant l'objet événement
et deuxièmement, les données reçues args qui sont déconnectées pour l'instant.
J'ai ma fenêtre de terminal sur mon bureau cette fois-ci, alors décalez la fenêtre
principale vers la gauche, assise à côté de 100 pixels et pourquoi 140, ce qui la rend verticalement centrée sur mon écran.
OK, maintenant, ayant cet auditeur sur le processus principal, la prochaine étape évidente est d'envoyer quelque
chose à ce canal pour rendre le James.
Cette fois, nécessitant un moteur de rendu IPSI.
Nécessite un électron, je vais exécuter l'époxy envoyé à partir d'un clic de bouton, donc ajouter un écouteur de clic créera le bouton dans
un deuxième élément doget de document par I. RÉ. talk étant l'ID attribuera à ce bouton
add event listener click avec un callback e étant l'événement de rappel dans lequel enverra un message au processus
principal.
Commencez par créer ce bouton de conversation dans le point d'index Demel un bouton avec I. RÉ. parler l'étiquette.
Ce discours signifie un processus et une pause pour garder cela sur sa propre ligne là-bas.
Je vais l'enregistrer et le fermer car nous ne ferons rien d'autre avec ce fichier et maintenant
que ce bouton est connecté, nous pouvons implémenter une méthode d'envoi époxy au processus principal, cette fois
avec le module de rendu époxy Epoxy Renderer DOT envoyer sur le canal nommé Channel One, qui est le canal sur lequel nous écoutons
dans le processus principal, en envoyant une simple chaîne de bonjour depuis la fenêtre principale.
Enregistrez les deux fichiers.
Comme mentionné, mon terminal est ouvert afin que nous puissions voir que le message de la fenêtre principale est reçu
sur le processus principal.
Cliquez sur ce bouton de conversation et cela fonctionne.
Nous obtenons cela verrouillé dans le terminal à partir de l'écouteur principal du processus.
Disons maintenant que nous voulons répondre à ce message à partir du processus principal où il a été reçu.
Pour ce faire, nous devons d'abord comprendre la nature de l'IPC par défaut.
IPC sur électron est asynchrone, ce qui signifie que cela envoie le message au processus principal et passe immédiatement à autre chose.
Il n'y a pas d'attente de réponse, pas de valeur de retour, rien.
Et c'est une bonne chose car cela ne provoque pratiquement jamais de blocage de l'exécution de JavaScript dans le
processus de rendu.
Donc, pour répondre à un message de rendu du processus principal, la première étape va être d'identifier le moteur de
rendu.
Le message provenait, rappelez-vous, d'un moteur de rendu étant un instant de fenêtre de navigateur, nous pouvons donc en avoir plusieurs.
La façon dont nous trouvons l'expéditeur est alors sur l'événement de l'auditeur.
Object e dot sender sender étant l'instance de contenu Web de la fenêtre du navigateur d'envoi appelant send.
Comme nous l'avons fait dans le moteur de rendu.
Nous devons à nouveau spécifier un canal sur lequel envoyer cela.
Il peut s'agir du même canal sur lequel il a été reçu ou d'un autre.
Cela ne fait vraiment aucune différence.
Je vais envoyer ceci sur un nouveau canal appelé Channel One Response.
Message reçu sur Channel One.
Merci de répondre avec une confirmation d'avoir reçu ceci, alors la messagerie asynchrone devra maintenant implémenter
un écouteur pour cette réponse dans la fenêtre principale de l'expéditeur.
Copiez ce nom de canal à l'écoute dans Renderer esquive exactement la même chose que dans le Maine, esquive avec le
moteur de rendu époxy sur la réponse du canal un.
Ce canal, nous envoyons la réponse sur passer un rappel.
Et déconnectez-vous des ogg, les données reçues.
Enregistrez à nouveau les deux fichiers.
Cliquez sur le bouton Parler.
Et immédiatement, lorsque le processus principal reçoit notre message sur Channel One, il répond à la réponse
Channel One, que nous écoutons et déconnectons dans notre fenêtre principale.
Envoi et écoute donc vraiment basiques des deux côtés.
Maintenant, vous avez peut-être remarqué que ABC mine n'a pas réellement de méthode d'envoi.
Alors, comment pourrions-nous envoyer directement du processus principal à un moteur de rendu?
Si vous vous souvenez il y a une minute, j'ai mentionné que l'expéditeur est l'instance de contenu Web du processus de rendu d'envoi,
ce qui est exactement ce que nous pouvons utiliser pour envoyer directement à un moteur de rendu spécifique.
Ensuite, par exemple, pour envoyer un message directement au moteur de rendu de la fenêtre principale.
Nous pouvons le faire sur le contenu Web de cette instance de fenêtre de navigateur, mais nous devons attendre que le
contenu Web ait fini de se charger et créer une fenêtre, attendez l'événement de chargement terminé comme nous l'avons fait plusieurs
fois maintenant.
Le contenu Web du point de la fenêtre principale sur a terminé le chargement en passant un rappel dans lequel nous pouvons maintenant envoyer un message
EPOXI à cette fenêtre avec le contenu du Web point de la fenêtre principale.
Donc, essentiellement, accéder à la méthode d'envoi à partir du contenu Web de ce moteur de rendu est exactement le même que nous le faisons lors
de l'envoi au processus principal depuis le moteur de rendu.
Je vais nommer cette boîte aux lettres en vous envoyant un courrier.
Ensuite, comme auparavant, nous devrons écouter cela dans le moteur de rendu.
Dupliquez à nouveau cet auditeur en écoutant sur la boîte aux lettres du canal, en vous déconnectant des arguments sauvegardés.
Et ils sont immédiatement après que le contenu Web est prêt, ce message est envoyé de la protestation principale directement
à ce moteur de rendu.
Notez également que jusqu'à présent, je n'ai envoyé que des chaînes simples dans les deux sens.
Mais ABC peut également envoyer d'autres types de données JavaScript.
Par exemple, modifiez ce message en un objet avec quelques propriétés.
Email juste en jeu.
Academy Dot TV et un entier indiquent une sauvegarde prioritaire.
Et là, nous recevons l'objet dans le moteur de rendu exactement tel qu'il a été envoyé par le processus principal,
l'objet étant une structure de données plus probable pour communiquer via IPSI.
OK, cela couvre les messages asynchrones par défaut.
Et bien que ce soit probablement la meilleure implémentation pour 99% des situations, IPC peut également envoyer
des messages synchrones.
Ceux-ci se comportent de manière très différente de la messagerie asynchrone par défaut.
Voyons donc un exemple.
Je vais commencer par écouter ce message synchrone sur le processus principal, en utilisant le même écouteur
que pour les messages asynchrones.
Dupliquez celui-ci.
Cette fois, en écoutant à nouveau le message sinc, juste pour donner un nom logique à ce que nous attendons sur
ce canal, je déconnecte à nouveau les données du message.
Et maintenant, la principale différence ici est que lors de l'envoi d'un message Synchronoss depuis le moteur de rendu,
ce message exige une réponse et bloquera tout le processus de rendu jusqu'à ce qu'il soit reçu.
Nous devrons donc gérer cela un peu différemment sur le processus principal.
Tout d'abord, implémentez à nouveau l'envoi sur le moteur de rendu dans ces boutons de
discussion, cliquez sur le gestionnaire, dupliquez la méthode d'envoi, en commentant l'envoi asynchrone du canal un, appelant cette fois send sync sur le message
Sync.
Avec le message en attente de réponse, qui recevra, comme avec tout code JavaScript Synchronoss standard,
comme valeur de retour de cette fonction, cette valeur de retour étant définie par le récepteur, le processus principal
de retour dans cet écouteur défini sur la valeur de retour des objets événement property, une réponse de puits du processus
principal.
Affecter la réponse à une variable dans la réponse du moteur de rendu.
Verrouillez ça.
Enregistrez les deux fichiers et gardez à l'esprit ce qui va se passer ici maintenant, lorsque je clique, cela enverra un message
synchrone au processus principal, ce qui signifie que toute cette fenêtre sera suspendue jusqu'à ce que nous obtenions
une réponse du processus principal qui renvoie la valeur cliquez .
Et là.
Cela s'est évidemment produit très rapidement, mais nous avons reçu ce message d'attente de réponse sur le processus
principal, un signe, une valeur de retour à l'événement de message, ce qui permet au moteur de rendu de continuer l'exécution et
de déconnecter cette valeur.
Gardez à l'esprit que la partie synchrone de ceci ne se produit que dans le moteur de rendu.
Le processus principal est simplement de répondre et bien sûr, être non ne peut être bloqué à aucun moment pour mieux démontrer
la nature de ce blocage de processus.
J'ajouterai un délai à cette réponse du processus principal.
Cependant, tout d'abord, dans le moteur de rendu, créez un intervalle de journal pour observer le blocage avec un intervalle défini.
Déconnexion, I.
Dit-je à un et incrémenter I après chaque journal, ce que je ferai une seconde, c'est trivial, mais cela nous permettra simplement de
voir le processus de blocage alors à l'esprit, toujours en utilisant un délai d'expiration, en définissant cette
réponse.
Je vais également commenter l'envoi au moteur de rendu.
Définissez le délai d'expiration, passez un rappel, définissez cette valeur de retour après, par exemple, quatre secondes, enregistrez les deux fichiers.
Nous voyons le journal chaque seconde, mais lorsque j'envoie le message, tout se bloque jusqu'à quatre secondes plus tard, cette valeur de réponse
est définie et le moteur de rendu peut continuer à exécuter le code.
Donc, comme vous pouvez le voir, c'est probablement quelque chose que vous devriez éviter d'utiliser la plupart du temps.
Mais il y aura des situations où la messagerie synchrone sera nécessaire.
Utilisez-le simplement à bon escient.
C'est essentiellement tout pour les modules IPSI.
Nous avons également quelques fonctions d'assistance de base, mais celles-ci sont assez explicites.
La possibilité de désinscrire l'écoute de la chaîne comme étant les principales.
Vous trouverez la messagerie ABC dans presque toutes les applications électroniques, alors assurez-vous d'avoir une bonne compréhension de ce
sujet.
Dans la prochaine leçon, nous examinerons quelques utilisations un peu plus avancées d'IPSI.